This section is new as of Version 1.2 of the Conformance Guide, but will not be marked with diffmarks.
The MIPS processor specific ABI defines the default library
search path to be /lib:/usr/lib:/usr/lib/cmplrs/cc.
This specification defines the default
library search path to be
/lib:/usr/lib:/usr/lib/cmplrs/cc:/opt/lib.
The /usr/lib/cmplrs/cc portion is deprecated and will
be dropped in a future version of this specification.
For MIPS ABI conforming programs, the program interpreter
(the contents of the PT_INTERP segment) shall be
/usr/lib/libc.so.1
After the dynamic linker has built the process image and performed the relocations, each shared object gets the opportunity to execute some initialization code. All shared object initializations happen before the executable file gains control.
Before the initialization code for any object A is called,
the initialization code for any other objects that object A
depends on are called. For these purposes, an object A
depends on another object B, if B appears in A's list of
needed objects (recorded in the DT_NEEDED entries of the
dynamic structure). The order of initialization for circular
dependencies is undefined.
The initialization of objects occurs by recursing through the needed entries of each object. The initialization code for an object is invoked after the needed entries for that object have been processed. In the case that more than one object is available for initialization, reverse resolution ordering will determine the initialization order.
The example on the following page illustrates correct initialization ordering. In this example the a.out is dependent on b, d, and e. b is dependent on d and f, while d is dependent on e and g. From this information a dependency graph can be drawn. The above algorithm on initialization will then allow the following specified initialization ordering.
Similarly, shared objects may have termination functions,
which are executed with the atexit(BA_OS)
mechanism after the base process
begins its termination sequence. The order in which the
dynamic linker calls termination functions is the exact
reverse order of their corresponding initialization
functions. If a shared object has a termination function,
but no initialization function, the termination function
will execute in the order it would have as if the shared
object's initialization function was present. The dynamic
linker ensures that it will not execute any initialization
or termination functions more than once.
Shared objects designate their initialization and
termination functions through the DT_INIT
and DT_FINI entries in the dynamic
structure, described in "Dynamic Section" in the generic
ABI. Typically, the code for these functions resides in the
and sections, mentioned in ``Sections'' of Chapter 4 of the
generic ABI. Although the termination processing normally
will be done, it is not guaranteed to have executed upon
process death. In particular, the process will not execute
the termination processing if it calls _exit [see or if the
process dies because it received a signal that it neither
caught nor ignored.
The dynamic linker is not responsible for calling the
executable file's section or registering the executable
file's section with atexit(BA_OS). Termination functions
specified by users via the atexit(BA_OS) mechanism must be
executed before any termination functions of shared objects.
Figure 1. Initialization Ordering Example (click to download)
Back to the Table of Contents
Back to the MIPS ABI Home Page
Copyright © 1995, MIPS ABI Group, Incorporated.